home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9802 / 000005_owner-linux-arm…r.rutgers.edu _Fri Feb 6 21:47:20 1998.msg < prev    next >
Internet Message Format  |  1998-04-07  |  5KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id VAA26765
  4.     for <willy@odie.fluff.org>; Fri, 6 Feb 1998 21:47:17 GMT
  5. Received: from vger.rutgers.edu ([128.6.190.2]:37712 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <10522-621>; Fri, 6 Feb 1998 23:46:48 +0200
  6. Received: by vger.rutgers.edu id <972391-5070>; Fri, 6 Feb 1998 14:09:48 -0500
  7. Received: from out5.ibm.net ([165.87.194.245]:4087 "EHLO out5.ibm.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <972790-5070>; Fri, 6 Feb 1998 10:13:54 -0500
  8. Received: from cvs.com.au (slip-32-100-14-5.fl.us.ibm.net [32.100.14.5]) by out5.ibm.net (8.8.5/8.6.9) with ESMTP id PAA89172 for <linux-arm@vger.rutgers.edu>; Fri, 6 Feb 1998 15:16:32 GMT
  9. Message-ID: <34DB29DA.93352C38@cvs.com.au>
  10. Date:     Fri, 06 Feb 1998 10:18:50 -0500
  11. From: Charles Esson <charlese@cvs.com.au>
  12. Reply-To: charlese@cvs.com.au
  13. Organization: Colour Vision Systems
  14. X-Mailer: Mozilla 4.04 [en] (WinNT; I)
  15. MIME-Version: 1.0
  16. To: "linux-arm@vger.rutgers.edu" <linux-arm@vger.rutgers.edu>
  17. Subject: Moving development off this mailing list
  18. Content-Type: text/plain; charset=us-ascii
  19. Content-Transfer-Encoding: 7bit
  20. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  21. Sender: owner-linux-arm@vger.rutgers.edu
  22. Precedence: bulk
  23. Status: RO
  24.  
  25. I have long felt that the linux-arm development effort has adopted the
  26. linux code but not the development method that made linux the success it
  27. is. The paper pointed to be the following URL discusses what the linux
  28. development method. I think it is probable the most significent writing
  29. on  the topic of project managment since the Mythical man month.
  30.  
  31. http://earthspace.net/~esr/writings/cathedral-paper.html
  32.  
  33. If you don't agree with me then please read the following extact from an
  34. email that was posted to this sight around Christmass. Russell's posting
  35. that led to this responce ( which I long ago zapped). Russell's earlier
  36. emails stating he didn't want to post the source for arm linux as he
  37. would get email from inexperienced users and so on.
  38.  
  39. As this posting is very blunt, I expect very blunt responces, but before
  40. you flame me please read the above paper.
  41.  
  42.  
  43.  
  44.  
  45. \
  46. -----------------------------------------------------------------------------------
  47. \
  48. > No Phil.  Your patch does the following:
  49. >
  50. > *     Changes the help descriptions for the ethernet cards.
  51.  
  52. That's true.  I hadn't particularly intended for that to leak into the
  53. patch.
  54.  
  55. > * Moves the kernel link address back to 0x1800000, which is where it
  56. was
  57. > originally.
  58.  
  59. Yes, on your advice.
  60.  
  61. > * Changes a few #definitions to to with processor and machine type
  62. with
  63. > no overall
  64. >       effect, especially the processor definitions.
  65. >       Do you really understand the meaning of the __arm2__ __arm3__
  66. > etc *compiler*
  67. >       definitions?
  68.  
  69. Yes.  gcc 2.8 doesn't define __arm2__ or __arm3__ if you give it the
  70. -mapcs= and -mcpu= options, so with the old #ifdefs you ended up getting
  71.  
  72. support for no CPUs at all.  You do still get __arm3__ defined with -m3,
  73.  
  74. but you also get complaints about this being an obsolete option.
  75.  
  76. > * Removes *all* support for the binutils currently supplied with the
  77. ARM
  78. > Linux
  79. >       distribution.
  80.  
  81. Since the support was 50% gone already, this strikes me as little
  82. hardship.  The binutils with this problem fixed has been available for
  83. months.
  84.  
  85. > *     Removes the floppy code's ARM architecture dependence.
  86.  
  87. Why, exactly, do you feel this is bad?  I'm slightly confused as to
  88. which
  89. patch you're talking about here.  The one I had last week removed the
  90. architecture dependence, and your reaction to that was "good".
  91. Unfortunately I goofed slightly and the result wouldn't compile
  92. properly (and I left out some debug stuff).  This newer patch remedies
  93. that; I don't understand your objection.
  94.  
  95. > * Slightly optimises the __xchg() function in terms of memory data
  96. > space.
  97.  
  98. ... and, more importantly, allows you to compile armksyms.c on a5k
  99. machines.
  100.  
  101. > * Unnecessarily changes the decompressor code.
  102. >       If your compiler can't hack that, then throw it away - it's not
  103. ANSI
  104. >       conformant, and must be broken.
  105.  
  106. It's gcc, and I don't know of any alternative.
  107.  
  108. > *     Various spelling corrections.
  109. I can't see that they do any harm either, though I agree that the world
  110. won't end without them.
  111.  
  112. > In effect, what Phil is trying to do is to remove as many changes as
  113. > possible to the driver code that has moved from the drivers
  114. directories
  115. > to the arch/arm/drivers heirarchy.
  116.  
  117. That's true, and last time I posted a patch to do this you were all in
  118. favour.
  119.  
  120. > What is the point in reversing some of the changes made to *improve*
  121. the
  122. > performance of the 2.0 kernels when we're moving towards the 2.1
  123. > kernels?
  124.  
  125. Because the fewer gratuitous changes we have, the less work there is to
  126. do
  127. with the merge.  If you want to fix 8390.c to go faster, then since it's
  128.  
  129. not an ARM specific change there's no need to make another copy of the
  130. file.
  131.  
  132. > There have been *no* bug fixes in this patch whatsoever, in fact,
  133. there
  134.  
  135. If that's your opinion, fine.  Merry Christmas, by the way.
  136.  
  137.  
  138.  
  139. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu